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Path Computation Element Communication Protocol 
(PCEP) Extensions for Establishing Relationships 
between Sets of Label Switched Paths and Virtual 
Networks 


Abstract 


This document describes how to extend the Path Computation Element Communication Protocol 
(PCEP) association mechanism introduced by RFC 8697 to further associate sets of Label Switched 
Paths (LSPs) with a higher-level structure such as a Virtual Network (VN) requested by a 
customer or application. This extended association mechanism can be used to facilitate control of 
a VN using the PCE architecture. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9358. 
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1. Introduction 


The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path 
Computation Elements (PCEs) to perform path computations in response to requests from Path 
Computation Clients (PCCs) [RFC5440]. 


[RFC8051] describes general considerations for a stateful PCE deployment and examines its 
applicability and benefits as well as its challenges and limitations through a number of use cases. 
[RFC8231] describes a set of extensions to PCEP to provide stateful control. For its computations, 
a stateful PCE has access to not only the information carried by the network's Interior Gateway 
Protocol (IGP) but also the set of active paths and their reserved resources. The additional state 
allows the PCE to compute constrained paths while considering individual Label Switched Paths 
(LSPs) and their interactions. 


[RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the 
stateful PCE model. 


[RFC8697] introduces a generic mechanism to create a grouping of LSPs. This grouping can then 
be used to define associations between sets of LSPs or between a set of LSPs and a set of 
attributes. 


[RFC8453] introduces a framework for Abstraction and Control of TE Networks (ACTN) and 
describes various VN operations initiated by a customer or application. A VN is a customer view 
of the TE network. Depending on the agreement between client and provider, various VN 
operations and VN views are possible. 


[RFC8637] examines the PCE and ACTN architectures and describes how the PCE architecture is 
applicable to ACTN. [RFC6805] and [RFC8751] describe a hierarchy of stateful PCEs with the 
parent PCE coordinating multi-domain path computation functions between child PCEs, thus 
making it the base for PCE applicability for ACTN. As [RFC8751] explains, in the context of ACTN, 
the child PCE is identified with the Provisioning Network Controller (PNC), and the parent PCE is 
identified with the Multi-Domain Service Coordinator (MDSC). 


In this context, there is a need to associate a set of LSPs with a VN "construct" to facilitate VN 
operations in the PCE architecture. This association allows a PCE to identify which LSPs belong to 
a certain VN. The PCE could then use this association to optimize all LSPs belonging to the VN at 
once. The PCE could further take VN-specific actions on the LSPs, such as relaxing constraints, 
taking policy actions, setting default behavior, etc. 


This document specifies a PCEP extension to associate a set of LSPs based on their VN. 
2. Terminology 


This document uses terminology from [RFC4655], [RFC5440], [RFC6805], [RFC8231], and 
[RFC8453]. 
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The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


3. Operation Overview 


As per [RFC8697], LSPs are associated with other LSPs with which they interact by adding them 
to a common association group. 


An association group based on VN is useful for various optimizations that should be applied by 
considering all the LSPs in the association. This includes, but is not limited to, the following: 


Path Computation: When computing a path for an LSP, it is useful to analyze the impact of this 
LSP on the other LSPs belonging to the same VN. The aim would be to optimize all LSPs 
belonging to the VN rather than a single LSP. Also, the optimization criteria (such as 
minimizing the load of the most loaded link (MLL) [RFC5541]) could be applied for all the LSPs 
belonging to the VN identified by the VN association. 


Path Reoptimization: The PCE would like to use advanced path computation algorithms and 
optimization techniques that consider all the LSPs belonging to a VN and optimize them all 
together during the path reoptimization. 


In this document, we define a new association group called the "VN Association Group (VNAG)". 
This grouping is used to define the association between a set of LSPs and a VN. 


The ASSOCIATION object contains a field to identify the type of association, and this document 
defines a new Association Type value of 7 to indicate that the association is a "VN Association". 
The Association Identifier in the ASSOCIATION object is the VNAG Identifier and is handled in the 
same way as the generic Association Identifier defined in [RFC8697]. 


In this document, "VNAG object" refers to an ASSOCIATION object with the Association Type set 
to "VN Association" (7). 


Local policies on the PCE define the computational and optimization behavior for the LSPs in the 
VN. An LSP MUST NOT belong to more than one VNAG. If an implementation encounters more 
than one VNAG object in a PCEP message, it MUST process the first occurrence, and it MUST 
ignore the others. 


[RFC8697] specifies the mechanism by which a PCEP speaker can advertise which Association 
Types it supports. This is done using the ASSOC-Type-List TLV carried within an OPEN object. A 
PCEP speaker MUST include the VN Association Type (7) in the ASSOC-Type-List TLV before using 
the VNAG object in a PCEP message. As per [RFC8697], if the implementation does not support the 
VN Association Type, it will return a PCErr message with Error-Type=26 (Association Error) and 
Error-value-1 (Association Type is not supported). 
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The Association Identifiers (VNAG IDs) for this Association Type are dynamic in nature and 
created by the parent PCE (MDSC) based on the VN operations for the LSPs belonging to the same 
VN. Operator configuration of VNAG IDs is not supported, so there is no need for an Operator- 
configured Association Range to be set. Thus, the VN Association Type (7) MUST NOT be present in 
the Operator-configured Association Range TLV if that TLV is present in the OPEN object. If an 
implementation encounters the VN Association Type (7) in an Operator-configured Association 
Range TLV, it MUST ignore the associated Start-Assoc-ID and Range values. 


This association is useful in a PCEP session between a parent PCE (MDSC) and a child PCE (PNC). 
When computing the path, the child PCE (PNC) refers to the VN association in the request from 
the parent PCE (MDSC) and maps the VN to the associated LSPs and network resources. From the 
perspective of the parent PCE, it receives a VN creation request from its customer, with the VN 
uniquely identified by the association parameters (Section 6.1.4 of [RFC8697]) in the VNAG or the 
Virtual Network Identifier encoded in the VIRTUAL-NETWORK-TLV. This VN may comprise 
multiple LSPs in the network in a single domain or across multiple domains. The parent PCE 
sends a PCInitiate message with this association information in the VNAG object. This in effect 
binds an LSP that is to be instantiated at the child PCE with the VN. The VN association 
information MUST be included as a part of the first PCRpt message. Figure 1 shows an example of 
a typical VN operation using PCEP. It is worth noting that in a multi-domain scenario, the 
different domains are controlled by different child PCEs. In order to set up the cross-domain 
tunnel, multiple segments need to be stitched by the border nodes in each domain that receive 
the instruction from their child PCE (PNC). 
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Figure 1: Example of VN Operations in H-PCE (Hierarchical PCE) Architecture 


Whenever changes occur with the instantiated LSP in a domain network, the domain child PCE 
reports the changes using a PCRpt message in which the VNAG object indicates the relationship 
between the LSP and the VN. 


Whenever an update occurs with VNs in the parent PCE (due to the customer's request), the 
parent PCE sends a PCUpd message to inform each affected child PCE of this change. 


4. Extensions to PCEP 


The VNAG uses the generic ASSOCIATION object [RFC8697]. 


This document defines one new mandatory TLV called the "VIRTUAL-NETWORK-TLV". Optionally, 
the new TLV can be jointly used with the existing VENDOR-INFORMATION-TLYV specified in 
[RFC7470] as described below: 


VIRTUAL-NETWORK-TLV: Used to communicate the Virtual Network Identifier. 
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VENDOR-NFORMATION-TLV: Used to communicate arbitrary vendor-specific behavioral 
information, as described in [RFC7470]. 


The format of the VIRTUAL-NETWORK-TLV is as follows. 


0 1 2 3 
8:152.3.475.767:8:97071721395475/677:809-071:2 53747576 7.82970: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type=65 | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| | 
Hit Virtual Network Identifier // 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 2: Format of the VIRTUAL-NETWORK-TLV 


Type (16 bits): 65 


Length (16 bits): Indicates the length of the value portion of the TLV in octets and MUST be 
greater than 0. The TLV MUST be zero-padded so that the TLV is 4-octet aligned. 


Virtual Network Identifier (variable): A symbolic name for the VN that uniquely identifies the 
VN. It SHOULD be a string of printable ASCII [RFC0020] characters (i.e., 0x20 to Ox7E), without 
a NULL terminator. The Virtual Network Identifier is a human-readable string that identifies 
a VN. It can be specified with the association information, which may be conveyed in a 
VENDOR-INFORMATION-TIV. An implementation uses the Virtual Network Identifier to 
maintain a mapping to the VNAG and the LSPs associated with the VN. The Virtual Network 
Identifier MAY be specified by the customer, set via an operator policy, or auto-generated by 
the PCEP speaker. 


The VIRTUAL-NETWORK-TLV MUST be included in VNAG object. If a PCEP speaker receives the 
VNAG object without the VIRTUAL-NETWORK-TLV, it MUST send a PCErr message with Error- 
Type=6 (Mandatory Object missing) and Error-value=18 (VIRTUAL-NETWORK-TLV missing) and 
close the session. 


The format of VENDOR-INFORMATION-TLV is defined in [RFC7470]. 


If a PCEP speaker receives a VNAG object with a TLV that violates the rules specified in this 
document, the PCEP speaker MUST send a PCErr message with Error-Type-10 (Reception of an 
invalid object) and Error-value=11 (Malformed object) and MUST close the PCEP session. 


5. Security Considerations 


The security considerations described in [RFC5440], [RFC8231], and [RFC8281] apply to the 
extensions defined in this document as well. 
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This document introduces the VN Association Type (7) for the ASSOCIATION object. Additional 
security considerations related to LSP associations due to a malicious PCEP speaker are described 
in [RFC8697] and apply to the VN Association Type. Hence, securing the PCEP session using 
Transport Layer Security (TLS) [RFC8253] is RECOMMENDED. 


6. IANA Considerations 


6.1. ASSOCIATION Object Type Indicator 


IANA has assigned the following new value in the "ASSOCIATION Type Field" subregistry within 
the "Path Computation Element Protocol (PCEP) Numbers" registry: 


Value Name Reference 
7 VN Association RFC 9358 
Table 1 


6.2. PCEP TLV Type Indicator 


IANA has assigned the following new value in the "PCEP TLV Type Indicators" subregistry within 
the "Path Computation Element Protocol (PCEP) Numbers" registry: 


Value Name Reference 
65 VIRTUAL-NETWORK-TLV RFC 9358 
Table 2 


6.3. PCEP Error 


IANA has allocated the following new error value in the "PCEP-ERROR Object Error Types and 
Values" subregistry within the "Path Computation Element Protocol (PCEP) Numbers" registry: 


Error- Meaning Error-value Reference 
Type 
6 Mandatory Object 18: VIRTUAL-NETWORK-TLV RFC 9358 
missing missing 
Table 3 


7. Manageability Considerations 


7.1. Control of Function and Policy 


An operator MUST be allowed to mark LSPs that belong to the same VN. This could also be done 
automatically based on the VN configuration. 
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7.2. Information and Data Models 


The PCEP YANG module [PCE-PCEP-YANG] should support the association between LSPs 
including VN association. 


7.3. Liveness Detection and Monitoring 


Mechanisms defined in this document do not imply any new liveness detection and monitoring 
requirements in addition to those already listed in [RFC5440]. 


7.4. Verification of Correct Operations 


Mechanisms defined in this document do not imply any new operation verification requirements 
in addition to those already listed in [RFC5440]. 


7.5. Requirements on Other Protocols 


Mechanisms defined in this document do not imply any new requirements on other protocols. 


7.6. Impact on Network Operations 


[RFC8637] describes the network operations when PCE is used for VN operations. Section 3 
further specifies the operations when VN associations are used. 
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